home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
windows
/
w31thd.zip
/
920416A.THD
next >
Wrap
Text File
|
1992-05-01
|
31KB
|
832 lines
#: 103351 S9/Script/Nav Pgms [C]
16-Apr-92 00:51:23
Sb: #Oz in Win 3.1
Fm: Michael Cain 74160,2326
To: Steve Sneed 70007,3574
Steve,
I know you're busy (is it true you have a regular day job too? <g>) and since
I'm able to do pretty much what I want with Ozcis, normally I wouldn't bother
you but I do have this one nagging little problem that's bugging me because I
don't understand it.
I can crash Ozcis fairly reliably when running under Windows 3.1. A number of
threads have touched upon this (some in regards to DOS only), and your general
response, if I may paraphrase it briefly, is that a heavy processor load can
cause any com program 'grief'.
What I don't understand is why this 'grief' isn't lost data as opposed to
program crash.
I've got a lot of hardware (graphics ultra, tape controller, TOPS flashcard,
SCSI board for cd-rom, MultiSound, IDE drives) in my machine (486/33 16MB) and
I've got a lot of drivers and TSR's to support all this, including QEMM 6.02
using Stealth and Smartdrv 4.0 with write-behind enabled. On top of all this, I
run windows 3.1. Nightmare city, huh?
Still, I've worked hard on configuration to maximize and optimize and at this
point the whole mess is rock solid and doing all it should. I've also been
running 3.1 for a couple months (got started on the beta late because I was
having a little fight with WLO at the time) and by now I've got some confidence
in my setup.
Here's how I break Ozcis. I run it in a window and do an online session at
9600 where a lot of text scrolls by (messages, lib scans, etc). If I'm full
screen or iconized, no problem. It doesn't crash right away, but will
eventually. If I want to hurry it up, I do things like run that little rle app
(the walking dog animation), play wave audio off the cd-rom, and (this is a
killer) toggle between full screen and window with alt-return.
All this points to what you're saying about processor load. The odd thing is
that I can do all this and be downloading (as opposed to scrolling) and
[OzCIS: Continued in next msg]
#: 103352 S9/Script/Nav Pgms [C]
16-Apr-92 00:51:31
Sb: #103351-Oz in Win 3.1
Fm: Michael Cain 74160,2326
To: Michael Cain 74160,2326
[OzCIS: Continued from previous msg]
all I can get is an occasional burp (bad block) and then the protocol picks up
and carries on. Data loss, no crash.
I don't have to run Oz in a window, but I just like to keep my eye on it
while I do other things.
I run another com program under similar circumstances to talk to a Tandem
host and it has not failed, although I have not stressed it like I have Ozcis.
Keeping in mind that I am a lowly application programmer, if there is
anything you can say to enlighten me about this problem, I sure would
appreciate it.
thanks for everything,
Michael
#: 103376 S9/Script/Nav Pgms [C]
16-Apr-92 09:24:41
Sb: #103352-Oz in Win 3.1
Fm: Steve Sneed [IBMNET] 70007,3574
To: Michael Cain 74160,2326
Mike - The most likely cause is interrupt conflict causing a stack crash. When
an interrupt service routine gets activated, it uses whatever stack is "active"
at that time. If the int occurs during a DOS service, for example, the ISR
uses DOS' stack. DOS' stack is quite small, so it's possible the ISR uses more
stack than DOS has allocated and things got south.
Often you can improve this by juggling the STACKS= command in your config.sys
file.
Steve
#: 103461 S9/Script/Nav Pgms [C]
16-Apr-92 20:13:39
Sb: #103376-Oz in Win 3.1
Fm: Michael Cain 74160,2326
To: Steve Sneed [IBMNET] 70007,3574
Steve,
Thanks for the tip. I was using 9,256. I bumped to 9,512 and failed then
16,512 and failed. Mind you I'm really abusing the system to cause these
failures. The last time I got a message I've never seen before: "This
application (windows!) now running in exclusive mode because of insufficient
memory", followed by an Ozcis crash. Memory?
Ed Hochman(?) started a thread in winadv on this, I'll track that.
I also got my all-in-1 cd today, I think I'll do a clean install on a
separate volume and use the vanilla config and experiment some more. I hope
I've made it clear that this isn't really a problem for me, I'm just curious
about this. If I can find a configuration I can't break, I'll let you know.
thanks again, Michael
#: 103472 S9/Script/Nav Pgms [C]
16-Apr-92 22:17:13
Sb: #103461-Oz in Win 3.1
Fm: Steve Sneed [IBMNET] 70007,3574
To: Michael Cain 74160,2326
Michael - You might try 0,0 if the others don't work.
Steve
#: 103494 S9/Script/Nav Pgms [C]
17-Apr-92 02:35:02
Sb: #103472-Oz in Win 3.1
Fm: Marc C. Brooks 76244,2345
To: Steve Sneed [IBMNET] 70007,3574
Steve,
I think we are definitly jelling on a real symptom. I have noticed no other
programs give the problem with locking up while writing to disk, and have not
had any problems when OzCIS is doing a file transfer. I am beginning to lean
towards something in the screen driver of Oz messing up when interrupts (COM,
HD, timer) arrive while it is painting (maybe) or scrolling the screen (more
likely). Do you think you could gander at that hunk of the code. I still
stand by the idea that either the interrup handler's stack or the PIC is
getting messed up.
Marc
#: 103504 S9/Script/Nav Pgms [C]
17-Apr-92 08:46:14
Sb: #103494-Oz in Win 3.1
Fm: Steve Sneed [IBMNET] 70007,3574
To: Marc C. Brooks 76244,2345
Marc - I agree that it's stack-related, but I'm curious as to why. OzCIS now
has no ISRs other than those in the libraries I'm using, which are very
stable... the video routines have been thru 6 or 7 years of refinement, and are
about as typical a set of direct-video write routines as you'll ever see... all
file I/O uses nothing but standard TP RTL calls, the only thing remotely
non-std is that I assign a larger buffer for the text files, which could be it
I guess, as the cache may not approve of 8K blocks at a shot under those
conditions.
Steve
#: 103595 S9/Script/Nav Pgms [C]
17-Apr-92 22:43:51
Sb: #103504-Oz in Win 3.1
Fm: Rick Harris 70224,1256
To: Steve Sneed [IBMNET] 70007,3574
Steve... If I may jump in here, this sounds an awful lot like a problem I ran
into several years ago during a Beta on DR's Concurrent. We were hanging the
system randomly with multiple tasks, but especially when the int load was high.
We discovered that in a couple of routines the programmer had used a
non-specific end of interrupt to terminate. And if I'm not mistaken, one of
them was in a video routine. With a heavy int load, the PIC would end up with
multiple ints nested. If a NEOI showed up in this situation, it was possible
for the wrong int to be terminated prematurely. Besides that, the one that was
supposed to be terminated was left hanging. The problem was immediately
eliminated when the NEOIs were replaced with specific EOIs.
Therefore, the scenario here makes me wonder if maybe there is a NEOI in use in
one of the library ISRs you are using. THis problem wouldn't show up until you
get into a context switching environment. Might be worth a look. I think I
mentioned this briefly in an earlier thread, but it seemed even more applicable
here.
Rick...
#: 103607 S9/Script/Nav Pgms [C]
18-Apr-92 01:07:49
Sb: #103595-Oz in Win 3.1
Fm: Steve Sneed [IBMNET] 70007,3574
To: Rick Harris 70224,1256
Rick - I know at least one is using a NEOI; I'll check the others. It's
certainly a possibility.
Steve
#: 103640 S9/Script/Nav Pgms [C]
18-Apr-92 11:13:57
Sb: #103607-Oz in Win 3.1
Fm: Rick Harris 70224,1256
To: Steve Sneed [IBMNET] 70007,3574
Steve... I went back and looked at the Concurrent XIOS source code this morning
to jog my memory (we debugged this back in 86). NEOIs had been used in the
floppy, hd, keyboard, and aux ISRs. All it took to eliminate the hang ups was
to change all occurances of the equates as follows.
from PIC_OCW_NEOI equ 020h to PIC_OCW_SEOI equ 060h
If this doesn't work, has consideration been given as to when the PIC gets
reset? The text block that follows might be of interest to you so I grabbed it
also.
;* SERIAL CARD INTERRUPT SERVICE ROUTINES *
; Three issues must be considered in these routines:
; 1) When to reset the PIC (Programmable Interrupt Controller);
; 2) When the UART interrupt line gets reset;
; 3) Whether and/or when to re-enable interrupts at the CPU.
; These routines reset the PIC near the top and keep interrupts disabled
; at the CPU for the duration of the ISR.
; Resetting the PIC at the top of the ISR could potentially cause the
; CPU to re-enter this ISR if, e.g., a modem status interrupt happens while
; still in the ISR from a receive interrupt, but after the interrupt line
; has been reset at the UART. The 8250 used in a PC/XT may protect against
; this, and so might the AT async. HW, but to be sure, we don't re-enable
; interrupts at the CPU (STI) in this ISR. That way we are sure to get
; all the way through.
; The other alternative is to reset the PIC at the bottom of the ISR, but
; that could possibly hang us up if the following happens:
; 1) RCV int occurs;
; 2) ISR reads UART data which resets UART int line, but...
; 3) Just before resetting the PIC and iretting, a modem status int
; happens;
; 4) The int line to the PIC is still high, but the ISR resets the PIC
; and irets;
; 4) The PIC is edge-triggered, so we never service the UART again.
; This last version keeps ints off at the CPU all the way through, and resets
[OzCIS: Continued in next msg]
#: 103641 S9/Script/Nav Pgms [C]
18-Apr-92 11:14:03
Sb: #103640-Oz in Win 3.1
Fm: Rick Harris 70224,1256
To: Rick Harris 70224,1256
[OzCIS: Continued from previous msg]
; the PIC at the top. It also never dispatches.
Rick...
#: 103670 S9/Script/Nav Pgms [C]
18-Apr-92 14:46:15
Sb: #103640-Oz in Win 3.1
Fm: Steve Sneed [IBMNET] 70007,3574
To: Rick Harris 70224,1256
Rick - Thanks. I'm forwarding this to Terry as well, since he wrote the port
ISR in Async Professional.
Steve
#: 103723 S9/Script/Nav Pgms [C]
18-Apr-92 22:43:47
Sb: Ver 1.1a now available
Fm: Steve Sneed [IBMNET] 70007,3574
To: All
All OzCIS Users:
I've just uploaded version 1.1a. This version improves the allocation
strategy for EMS/XMS and adds checks for the infamous "NOEMS" switch problem,
adds disk virtual memory to the other two virtual memory capabilities, adds
support for non-standard commport base addresses and IRQs, adds a definable
modem reset string in addition to the init string, adds a new /W command line
switch to allow multiple copies to be run under multiaskers such as Windows and
OS/2, adds a new "PARITY" script command to make life easier for users going
thru older modem pools and/or phone switches, makes adjustments to (hopefully)
eliminate the problems some users experience under Windows or with lots of
active TSRs/drivers, makes a mod to improve the problem with bogus timeout
warnings under OS/2, and addresses several other nits. Recommended upgrade,
especially if you're running under Windows or OS/2.
The new version will be available sometime after 1:00am.
Steve
#: 103768 S9/Script/Nav Pgms [C]
19-Apr-92 12:53:42
Sb: #103723-Ver 1.1a now available
Fm: Michael Cain 74160,2326
To: Steve Sneed 70007,3574
Steve,
I have tried 1.1a under the circumstances described previously and it will
still fail as before. I have also done a clean windows install with a 'vanilla'
config as well as a 'bare bones' config with similar results, although it seems
as if the more physical memory I give to windows the more robust it is. I am
really just looking for the optimal configuration here so that under normal use
I can make the possibility of an Ozcis crash as remote as possible.
I think I've got a handle on autoexec.bat, config.sys and ozcis.pif. Now I'm
looking at system.ini. I have a couple ideas, I wonder if you would give an
opinion.
1) remove the comport from the windows domain by setting COMxIrq=-1. This
should still allow a DOS app to use it but without going through the windows
virtualization, thus eliminating some overhead and complications. I haven't
tried this but I think it should work.
2) If that's not a good idea, how about bumping COMxBuffer and COMBoostTime?
thanks Michael 'thanks for /w' Cain
#: 103786 S9/Script/Nav Pgms [C]
19-Apr-92 14:52:10
Sb: #103768-Ver 1.1a now available
Fm: Steve Sneed [IBMNET] 70007,3574
To: Michael Cain 74160,2326
Michael - Juggling the system.ini options relative to the comm port may well
need to be done. I've never tried turning off the port completely in Windows
so I can't say how that would work, but it's worth a try.
Steve
#: 104004 S9/Script/Nav Pgms [C]
21-Apr-92 00:14:34
Sb: #103786-Ver 1.1a now available
Fm: Michael Cain 74160,2326
To: Steve Sneed [IBMNET] 70007,3574
Steve - ComxIrq=-1 to turn off the port in windows made it worse, but it may be
you have to do more than just that. It was effective in the sense that windows
didn't know about the port and Oz did. I tried ComxBuffer=16384 and
ComBoostTime=8 and I couldn't tell the difference but at least it didn't hurt.
Michael
#: 103817 S9/Script/Nav Pgms [C]
19-Apr-92 19:24:44
Sb: #103723-Ver 1.1a now available
Fm: Ed Hochman 70363,1300
To: Steve Sneed 70007,3574
Steve,
Sorry to be the bearer of bad news, but I just downloaded the latest version,
ran it under Win 3.1 and bang! It got killed by Windows.
After leaving Windows and doing a CHKDSK /F, I ended up with two \FILE*.CHK
files. The first looks like a complete session log.
I noticed that your PIF file has a /S option. I guess that explains the ses
sion log.
The second file is the 7 or 8 quick scan headers from the fourm that was being
queried when Oz died.
With the previous version, the failure seemed to occur only when there were
lots of message headers for the quick scan. This time, it is either worse, or
building the session log contributed to the problem.
Sorry again. Ed.
P.S. As a suggestion. It might be a good idea to distribute the FOURMS.DB and
other startup files in a separate EXE that would generally be used by new
users. If your not carefull (I wasn't) these files can clobber the user's
defaults.
#: 103834 S9/Script/Nav Pgms [C]
19-Apr-92 21:12:16
Sb: #103817-Ver 1.1a now available
Fm: Steve Sneed [IBMNET] 70007,3574
To: Ed Hochman 70363,1300
Ed - Somehow, I'm not surprized. Sigh... I think I'll go throw myself out a
Windows. <g> Sheesh, I wish I could duplicate the problem! Windows works fine
for me.
I've got one or two more ideas up my sleeve, but they're the "Do you *really*
want to do that?" kind. I'm uploading a new OZCIS2.EXE in just a few, that has
one of those changes.
One thing I'd like to know: does turning off the session log help or eliminate
the problem?
BTW, the .DB files are all in the OZCIS3.EXE archive, which normally isn't
required for an update.
Steve
#: 103902 S9/Script/Nav Pgms [C]
20-Apr-92 12:58:55
Sb: #103834-Ver 1.1a now available
Fm: Ed Hochman 70363,1300
To: Steve Sneed [IBMNET] 70007,3574
Steve,
I wish I could help with some ingenious insight. Alas, I can only guses.
My best guess is that there are too many interrupts going on with Oz, Win,
Stacker and Hyper386 and QEMM (w/Stealth). But I saw part of the thread
regarding the wrong type of interrupt -- thats out of my field.
<<does turning off the session log help or eliminate the problem?>> Yes. As
far as I can tell, the problem occurs when disk output is delayed -- I don't
know if it's being cached by Hyper386 of if OzCIS is buffering it in RAM. The
problem seems to occur when the file is committed to disk.
It seems that if the file is small -- as in a few messages being downloaded, or
a reasonalbly small list of message headers, there is no problem. But if the
file is big -- say 100 or more headers or perhaps a session log, the system
locks.
I tried the Dr. Watson utility that comes with Win 3.1. It was useless. After
the crash, Dr. Watson reportes no errors detected. And this is after Win 3.1
has issued a message and shut down Oz.
P.S. I saw that the DB files were in OZCIS3 -- after I started un-packing i t,
but didn't know what else might be in there or even that I didn't need the DB
files. As I say, I was careless <s>. Perhaps a message in the README might
help others not make the same mistake.
There are also some EXEs, a DOC and a few other usefull items in OZCIS3. I
think it might be worthwhile to have an OZCIS5 with _just_ those files that are
needed for the initial install.
Good luck. If anyone can find the problem, I know you can <g>. Ed.
#: 103826 S9/Script/Nav Pgms [C]
19-Apr-92 20:35:53
Sb: #103723-Ver 1.1a now available
Fm: Greg Dolan 70703,2663
To: Steve Sneed [IBMNET] 70007,3574
Just tried 1.1a. Worked fine under DOS. Under WIN 3.1 (using the .pif provided,
then another posted by Gabe) it crashed windows 2 out of 2 times with "This
application has violated system integrity due to execution of an invalid
instruction and will be terminated". Had to exit windows & reboot the system to
clear the 'problem.' Tried in window & full-screen modes (1 failure each).
Running 9600 bps LAPM connect. Screen said I had 724kE & 202560 just before
dialing. After connect the 724kE was no longer displayed. Test was reading all
messages in all forums on Practice. In DOS the memory displayed is 826kE &
180312...
Help?
#: 103842 S9/Script/Nav Pgms [C]
19-Apr-92 22:13:53
Sb: V1.1(3) online processor
Fm: Steve Sneed [IBMNET] 70007,3574
To: All OzCIS/Windows users
All OzCIS Users:
I've just uploaded to 9 a new version of the online processor module, 1.1(3).
This version makes some low-level mods to the comm ISR and other ISRs in the
program, and modifies the capture and session-log file I/O for better
performance. These mods are strictly to attempt to improve reliability under
Windows. Also fixed a nit in the handling of alternate base addresses/IRQs.
This update is available to all, but is intended primarily for those users
experiencing problems under Windows at high speeds. Please let me know if this
version improves things for you.
The file will be available shortly after 1:00am MDT.
Steve
#: 103863 S9/Script/Nav Pgms [C]
20-Apr-92 04:38:22
Sb: #103842-V1.1(3) online processor
Fm: Michael Cain 74160,2326
To: Steve Sneed [IBMNET] 70007,3574
Steve - V1.1(3) still fails. The good news is I know what induces the crash, at
least for me. Data overrun. I turned off flow control on my 9600 baud host, put
Ozcis in a window and then started an online session that does a bunch of
scrolling. It failed right away, repeatedly. That's with no other load on the
system, but as you know, scrolling in a window is a load by itself. Hope this
helps.
Michael
#: 103878 S9/Script/Nav Pgms [C]
20-Apr-92 09:19:30
Sb: #103863-V1.1(3) online processor
Fm: Steve Sneed [IBMNET] 70007,3574
To: Michael Cain 74160,2326
Michael - High speed with no flow control under Windows is a crash waiting to
happen. (High speed without flow control under DOS can be dangerous as well.)
Are you saying that when you turn on flow control the problem goes away?
Steve
#: 103911 S9/Script/Nav Pgms [C]
20-Apr-92 13:52:08
Sb: #103878-V1.1(3) online processor
Fm: Michael Cain 74160,2326
To: Steve Sneed [IBMNET] 70007,3574
Steve - Yes it does go away. Or more precisely (IMHO) it becomes infrequent. We
must not be on the same page here. Let me tell you where I'm coming from. I
have the idea that it is generally considered rude for a program to crash no
matter what the _user_ provocation. Garbage in, garbage out, okay. In the
extremis, I would like to see a program terminate as gracefully as possible,
eg, close files, issue a warning, etc. With regards to a com program, if it
can't keep up, for whatever reason, I would expect data loss. If I'm collecting
messages, a few characters get dropped. If I'm in a protocol, a block gets
retransmitted. If I'm in a script, I lose sync maybe. I think a crash should be
avoidable.
I also have the idea that even with flow control data overrun is not entirely
avoidable. I think of it as a standard error that a com program should be able
to deal with.
You are telling me to expect a crash. You are an expert and I would be
willing to accept this from you out of respect. But do me a favor if you can
and tell me about the mechanism of this crash and why it is you can do nothing
about it.
I remain an Ozcis and Steve Sneed (and Windows) fan.
Michael
#: 103964 S9/Script/Nav Pgms [C]
20-Apr-92 21:43:24
Sb: #103911-V1.1(3) online processor
Fm: Steve Sneed [IBMNET] 70007,3574
To: Michael Cain 74160,2326
Michael - You're right, we were on different pages. If it sounded like I meant
that a data overrun should equal a crash, sorry; that's not at all what I
meant. Like you, I agree that a data overrun situation should be handled
gracefully. The program should never do more than drop chars in an overrun; if
a UART overrun is indeed the problem, I would expect OzCIS to do exactly that
(and indeed, testing forced overruns at 115Kbps shows that OzCIS will do just
that.)
The real issue is not a simple UART overrun, though - it's a case of ISR
overrun, where the actual ISR code gets into a loop with itself or another ISR
and looses track of itself. This can happen to just about any software under
the right conditions, but OzCIS is more sensitive to it than many programs
because it's doing a good bit more than the average comm program and the
potential is higher.
Steve
#: 104005 S9/Script/Nav Pgms [C]
21-Apr-92 00:14:41
Sb: #103964-V1.1(3) online processor
Fm: Michael Cain 74160,2326
To: Steve Sneed [IBMNET] 70007,3574
Steve - Do you know this is happening? With Ozcis in a window, will forced
overruns cause a crash in your system? Do you imagine this is what is happening
to me when I get the occasional crash under normal use? (well what I call
normal <g>)
BTW, you were right about windows going to the video bios for the mode
switch. Also for a palette set using 16 colors.
Michael
#: 104016 S9/Script/Nav Pgms [C]
21-Apr-92 01:14:13
Sb: #104005-V1.1(3) online processor
Fm: Steve Sneed [IBMNET] 70007,3574
To: Michael Cain 74160,2326
Michael - I haven't tried forcing it under Windows; that was testing I did
quite a while back, using a special dummy "driver" to simulate CIS feeding data
to the program, and a modified OzCIS that allowed bps rates up to 115Kbps.
Yeah, on lots of video BIOS', interrupts are disabled for a full retrace cycle
(1/60th of a second). At 9600bps that's between 16 and 20 chars dropped; even
a 16550A UART won't catch 'em all. It shouldn't be a crash-causing situation,
just cause dropped chars, but under Windows there's a lot more going on... I
first learned this the hard way writing OZRLE, and had to go to a scheme of
sending an XOFF, waiting for the data stream to quiese, changing modes, and
then sending an XON.
Steve
#: 104403 S9/Script/Nav Pgms [C]
23-Apr-92 16:49:29
Sb: Ver 1.1b now available
Fm: Steve Sneed [IBMNET] 70007,3574
To: All OzCIS Users
All OzCIS Users:
I've just uploaded version 1.1b. This version adds:
Tweaked XMS allocation strategy once again to improve performance. Added
"Send Via Mail" option to the "Forward to Mail" capability in the forum
Reply Editor; this option, instead of forwarding the reply thru the
forum's message system, places the reply as a new message directly into
the CISMAIL.REP file, and allows receipt requests on such messages.
(Note that splitting directives in the reply message are removed when
using Send Via Mail.) Add ability to define the file name for SaVed
(individual) replies, so that you can keep saved copies of both messages
and their replies in one file or keep topical files more easily. Added
a local stack to the port ISR to (once again) attempt to improve
reliability under Windows. Removed the block from printing or saving
the Forum Header Message. Fixed glitch in Group Numbers when performing
a text search. Added logic to QS Headers display to check the current
messages file for headers that are for already-received messages (this
in preparation for several enhancements to QS support); such messages
will have a "smiley-face" char next to their entries in the QSList
display.
All Windows users please download the OZCIS2.EXE file at least, and let me know
if it improves your operations under Windows. Thanks!
Steve
#: 104467 S9/Script/Nav Pgms [C]
23-Apr-92 22:39:18
Sb: #104403-Ver 1.1b now available
Fm: Michael Cain 74160,2326
To: Steve Sneed [IBMNET] 70007,3574
Steve - Looks like you nailed it this time. The worst I can get out of Oz with
heavy abuse is a continuous beeping, which I suspect you put in there to punish
evil-doers. Congrats.
Michael
#: 104478 S9/Script/Nav Pgms [C]
23-Apr-92 23:06:53
Sb: #104467-Ver 1.1b now available
Fm: Steve Sneed [IBMNET] 70007,3574
To: Michael Cain 74160,2326
Michael - No, not punishment. <g> That's the port error handler beeping to let
you know an overrun occured. The beep is annoying; I'm going to change it.
Steve
(In honor of Earth Day, this message was composed and delivered using 100%
recycled electrons.)
#: 105158 S9/Script/Nav Pgms [C]
28-Apr-92 14:53:37
Sb: #104403-Ver 1.1b now available
Fm: James R. Wilentz 73730,1641
To: Steve Sneed [IBMNET] 70007,3574
Steve--
<Tweaked XMS allocation strategy once again to improve performance.>
Does this mean that I can run Ozcis without EMS enabled??? I've been running
with EMM386 in ram mode, but that doesn't seem to let me load anything else
high.
Bummer. Not.
--Jim
#: 105450 S9/Script/Nav Pgms [C]
29-Apr-92 23:00:18
Sb: #105158-Ver 1.1b now available
Fm: Steve Sneed [IBMNET] 70007,3574
To: James R. Wilentz 73730,1641
James - Yes, you can now run with just XMS.
Steve
#: 104954 S9/Script/Nav Pgms [C]
27-Apr-92 10:44:27
Sb: Possible STACKS conflict
Fm: Ed Hochman 70363,1300
To: Steve Sneed 70007,3574
Steve - Something odd happened while trying to download V1.2 (using v1.1b).
My computer locked two times while downloading OZCIS1.EXE.
This has never happened before. All my previous problems have been with
downloading message headers -- one time, I think the SESSION.LOG may have
caused the problem.
I decided to up STACKS to 9,512 (from 9,256). The next attempt to get OZCIS1,
died even sooner. The first two attempts got up to about 80% or 90% of
completion. The third didn't even get to 10%.
The only change I had made to my system recently, was going from STACKS 0,0 to
9,256. So I went back to 0,0. I was then able to get OZCIS1 and 2 with no
problems.
While I was changing my CONFIG (STACKS were at 9,512) I got a STACK OVERFLOW
SYSTEM HALTED message. This was while I was in DOS, Oz wasn't even running. I
had loaded SK to change CONFIG, and it was active at that time (but not when Oz
was running).
Could STACKS other than 0,0 cause a problem? Seems very strange. Maybe DOS
works differently if STACKS (other than 0,0) are in effect. Maybe this is
telling me about some problem/defficiency in my system.
Anyway, I now have V1.2. I'll let you know how it goes.
Ed.
#: 105034 S9/Script/Nav Pgms [C]
27-Apr-92 20:47:24
Sb: #104954-Possible STACKS conflict
Fm: Steve Sneed [IBMNET] 70007,3574
To: Ed Hochman 70363,1300
Ed - With 1.2 you shouldn't need any STACKS statement, or only STACKS=0,0. The
stacks statement is really only to give DOS and Windows an extra level of
protection from ill-behaved programs - which OzCIS certainly has been under
Windows. <g> I'm quite certain we've nailed this one down, though.
Rich and I did a good bit of testing at work today under Windows, using some
other test comm programs built using the same code as OzCIS 1.1a, and the
current 1.2 version of OzCIS. We were able to repeatedly reproduce the lockup
problem with the test programs and completely unable to get 1.2 to do anything
remotely bad-mannered.
For the technophiles: The original APro code did not set up a local stack for
the port ISR, because it's stack usage was small and ints were kept off for
most of the ISR's duration. Under Windows 3.x in Enhanced mode, however, the
VM manager in Windows is virtualizing interrupts for the process; while OzCIS'
VM had interrupts off, the rest of Windows has ints ON, and sooner or later
OzCIS was going to end up on a very "short" stack and crash. I added a local
stack to the ISR, which cured the problem.
Steve
#: 105225 S9/Script/Nav Pgms [C]
28-Apr-92 21:46:19
Sb: #105034-Possible STACKS conflict
Fm: Ed Hochman 70363,1300
To: Steve Sneed [IBMNET] 70007,3574
Steve - I agree. Oz now works under Windows without locking up!
But now, and this is a BIG improvement, I get a Port error message on the
status line. Something about the buffer being full. I didn't catch the whole
message, but I'm sure you know it.
Is there anything I can do about this? I'm afraid I'm loseing info.
One simplistic suggestion -- why not _not_ set the high message counter if the
port error occurs during a QS Header download? At least I'd get a second
chance.
That isn't an ideal solution, but it would help.
Do I need a faster computer? Please say yes, I'm looking for an excuse. But
seriously, you'ld think a 386/20 with cached RAM would be good enough.
Perhaps there is a way to fine tune Windows and/or Oz to tweek better
perforance. Or maybe I should shut off delayed cache writes while downloading.
Thanks for all your hard work on this and for a _great_ system.
Ed.
#: 105250 S9/Script/Nav Pgms [C]
28-Apr-92 23:06:30
Sb: #105225-Possible STACKS conflict
Fm: Steve Sneed [IBMNET] 70007,3574
To: Ed Hochman 70363,1300
Ed - YOU NEED A FASTER COMPUTER. There, I said it. <g>
Seriously, a 20MHz machine should be able to keep up, but it's probably going
to require some tuning on your part. Steve Walen's exellent thread on tuning
Windows for comm program performance should be considered required reading.
Steve
#: 105415 S9/Script/Nav Pgms [C]
29-Apr-92 20:23:59
Sb: Mouse is now Working
Fm: William S. Herndon 76530,1003
To: Steve Sneed 70007,3574
Steve,
The latest version of OZCIS (1.2) seems to have fixed my mouse problem. I
now have mouse support even a Windows 3.1 window every time I bring up the
application. Thanks.
Scott.